When ld reads a DSO, it adds all the symbols from that DSO to a cumulative symbol table. If it encounters a symbol that's already in the symbol table, it does not change the symbol table entry. If you define the same symbol in more than one DSO, only the first definition is used.
When ld reads an archive, usually denoted by a filename ending in .a, it uses only the object files from that archive that can resolve currently unresolved symbol references. (When a symbol is referred to but not defined in any of the object files that have been loaded so far, it's called unresolved.) Once a library has been searched in this way, it is never searched again. Therefore, libraries should come after object files on the command line in order to resolve as many references as possible. Note that if a symbol is already in the cumulative symbol table from having been encountered in a DSO, its definition in any subsequent archive or DSO is ignored.
ld myprog.o /usr/lib/libc.so.1 mylib.so
Note: libc.so.1 is the name of the standard C DSO, replacing the older libc.a. Similarly, libX11.so.1 is the X11 DSO. Most other DSOs are simply named name.so, without a .1 extension. To use the linker's library search rules, specify the library with the -lname option:
When the -lmylib argument is processed, ld searches for a file called libmylib.so. If it can't find libmylib.so in a given directory, it tries to find libmylib.a there; if it can't find that either, it moves on to the next directory in its search order. The default search order is to look first in /usr/lib, then in /lib.ld myprog.o -lmylib
If ld is invoked from one of the compiler drivers, all -L and -nostdlib options are moved up on the command line so that they appear before any -lname option. For example, consider the command:
This command invokes, at the linking stage of compilation, the following:cc file1.o -lm -L mydir
ld -L mydir file1.o -lm
Note: There are three different kinds of files that contain object code files: non-shared libraries, PIC archives, and DSOs. Non-shared libraries are the old-style library, built using ar from .o files that were compiled with -non_shared. These archives must also be linked -non_shared. PIC archives are the default, built using ar from .o files compiled with -KPIC (the default option); they can be linked with other PIC files. DSOs are built from PIC .o files by using ld -shared; see Chapter 3 for details. If the linker tells you that a reference to a certain function is unresolved, check that function's reference page to find out which library the function is in. If it isn't in one of the standard libraries (which ld links in by default), you may need to specify the appropriate library on the command line. For an alternative method of finding out where a function is defined, see "Finding an Unresolved Symbol With ld."
Note: Simply including the header file associated with a library routine is not enough; you also must specify the library itself when linking (unless it's a standard library). No automatic connection exists between header files and libraries; header files only give prototypes for library routines, not the library code itself.
To specify the appropriate DSOs for a graphics program foogl.c, enter:cc foo.c -lm
cc foogl.c -lgl -lX11